【レポート】プロトタイピングのススメ ― 手早くサービスを作って検証するための実践的ノウハウ AWS-12 #AWSSummit

AWS Summit Tokyo 2023

#AWS

森田力

2023.04.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。森田です。

本記事はAWS Summit Tokyoで行われたセッション「AWS-12 プロトタイピングのススメ ― 手早くサービスを作って検証するための実践的ノウハウ」のセッションレポートです。

セッション視聴

AWS Summit Tokyoの登録を行うことでオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。）

セッション概要

スピーカー

アマゾンウェブサービスジャパン合同会社

デジタルトランスフォーメーション本部プロトタイピングエンジニア

友岡雅志氏

セッションで取り上げること

AWS でプロトタイピングを効率的に行うノウハウ
業界に依らず普遍的に役立つ知識

前提知識

CI/CD、自動化テストなどといったモダンな開発手法に関する基礎的な知識
AWS を使った開発の基礎的な経験

セッションで説明しないこと

特定のユースケースに対する具体的技術紹介・比較

セッション内容

プロトタイピングとは
- プロトタイプを作る営み
- 最重要のスコープに限り短期間で必要な検証を行う
プロトタイピングが役に立つお悩み
- 机上で考えたアーキテクチャを実装したが、期待通りに動かなかった
- 考慮外の問題が発生して、技術選定からやり直しになった
- Fail fast
  - プロトタイピングにより早期に問題を見出す
プロトタイピングが生みがちなお悩み
- 素早く進めることができない
- 雑に動かすときに AWS は向いているのか
プロトタイピングのノウハウ
- 明確な目的と最小限の「スコープ」
- 「かっこいい」アーキテクチャ、禁止
- AWS サービスの抽象度を「上げる」
- 「完璧に」進める必要はありません
- 「爪を研ぐ」ことの重要さ
プロトタイピングのフェーズ
- 要件定義
- アーキテクティング
- ビルディング
- その後
要件定義
- 明確な目的と最小限の「スコープ」
- プロトタイピングの目的は
  - 前提を明確にし、チームで合意
    - なぜプロトタイプを作るか
    - プロトタイプで検証したい項目
    - 項目ごとの優先度
  - Why?
    - 後の意思決定が迅速になる
    - 方針のブレによる手戻りを防ぐ
  - プロトタイプの「形」を明らかにする
    - メンバーごとで見えているプロトタイプの形が違うことがある
      - すり合わせ・合意をとり、うやむやにしない
  - 目的から開発スコープが決まる
    - 開発スコープはいたずらに広げるべきではない
      - 検証開始が遅くなる
アーキテクティング
- 「かっこいい」アーキテクチャ、禁止
- 設計時には多くの意思決定が必要
- 設計のコツ : 不要な複雑化はしない
  - 必要のない限りはシンプルに
    - 低い開発コスト・認知負荷
    - チームによって何がシンプルかは変わる
  - 自然と複雑な方向に進んで行きがち
    - これを阻止する力
      - 要件の見直し
      - 目的の再確認
      - 思考のバイアスを排除
- アンチパターン例
  - 先読みをし「すぎ」た技術選定
  - 早すぎる最適化
  - 明確な課題意識なく「かっこいい」パターンを導入する
    - 流行しているパターンをとりあえず採用する
    - 特定技術の検証がプロトタイプの目的である場合はOK
  - 必要性が見えたときに最低限の複雑化をすることを繰り返す
ビルディング
- AWS サービスの抽象度を「上げる」
  - AWS の特徴 : AWSビルディングブロック
    - 所望のワークロードを細やかに設定できる
  - さらに便利にする
    - 抽象度が上がれば、学習・構築コストは下がる
    - 個々のリソースではなく、パターンとして抽象化
  - AWS Cloud Development Kit （CDK）
    - AWS 公式の IaC
    - L3 : 特定ユースケースの抽象化
    - L2 : 一般ユースケースの抽象化
    - L1 : CloudFormationリソースと1対1
    - 抽象度を上げて、下げることができる
      - L2で生産性を保ちつつ、L1で柔軟性を得る
- 「完璧に」進める必要はありません
  - 実装そのものよりも検証結果に価値がある
  - 「目先のスピード」と「後々の問題を先読みする」の良い塩梅を目指す
  - トレードオフ・投資対効果を考える
  - 技術的負債 = 悪者？
    - ベストプラクティスを踏襲することが常に最善ではない
    - 将来ベストプラクティスとしなかったことに対しての是正が求められる可能性がある
    - プロトタイプの目的に沿えば、負債が理に適うこともある
      - 将来的に「負債」にならないことも
その後
- 「爪を研ぐ」ことの重要さ
  - 経験が物を言う
    - 様々な意思決定を自信をもって素早く行う必要がある
  - プレ・プロトタイプ活動
    - 使ったことのない技術などをやってみる
    - 「やったことある」を積み重ねる
  - クロージングレビュー
    - プロトタイピングが終わった後に振り返りをする
      - 社内や社外（コミュニティ）などで
    - より大きなフィードバックループを作る
但し書き
- 「とりあえずやってみる」が最強
  - 初期フェーズの失敗は取り返しが効きやすい
- 「やってみて」経験を積む
まとめ
- プロトタイピングで早期に問題に気づく
  - Fail fast の手段として活用
- 抽象化が高速なプロトタイピングの鍵
  - 1つの方法として AWS CDK
- 経験こそ成功の礎
  - 「とりあえず試してみる」
Call to Action
- より Fail fast なアプローチを取り入れないか、チームで議論
- 「ベストプラクティス」のトレードオフ表をチーム状況に応じて埋めてみる
AWS JP Prototyping チームブログ
- https://prototyping-blog.com/